Now that bytecodealliance#251 and bytecodealliance#256 make it possible for more than one benchmark to
live in a single directory, this change moves all of the shootout
artifacts into a single directory. This simply performs the file
movement; subsequent commits will make necessary tweaks.

This change refactors how the shootout native benchmarks are built. The
`Dockerfile.native` file is retained and is expected to be _the_ way to
build the native shared libraries for this kind of benchmarking. A
`build-native.sh` script is included in the directory to (a) be used by
`Dockerfile.native` and (b) for building the native benchmarks in
environments where running Docker may not be possible.

Now that all of the benchmarks are built in one directory, the native
libraries cannot all be named `benchmark.so`. Because of this and the
hard-coded path expected by the native engine (see bytecodealliance#259), this change
also modifies the associated `*-native.sh` scripts to set up a temporary
directory that looks like the `benchmark.so` environment that was there
previously. This additional logic could be removed once bytecodealliance#259 is fixed.

These are all migrated over to be a part of the single `shootout`
directory.

The new file structure for `shootout` now expects these paths to look
like `shootout-ackermann.*.input`.

When we allocate the array to sort, we should do so with items of size
`double` (64 bits) instead of `double*` (32 bits in WebAssembly). I am
very confused as to why this benchmark worked previously, but when I
recompiled it prior to this change, it would invariably fail due to
accessing addresses beyond the memory bounds.

This change fixes some issues highlighted by CI:
- it adds more verbose output to see which commands are executed
- it improves the documentation to clarify how to use certain flags
- it fixes slight mistakes in the scripts missed by previous refactoring
- and, __most especially__, it alters the order of the parameters passed
  to compile the native libraries.

This last change is indicative of the fragility of the native
benchmarks: apparently moving `-lengine` to the end was necessary for
the linker to understand which library provides `bench_start` and
`bench_end`.

Now that `Dockerfile.native` relies on a script, `build-native.sh`,
instead of the Cargo build system, the documentation for building native
libraries has to change.